Radio terminal with browser

ABSTRACT

A terminal for providing an application using a browser. The terminal comprises a transceiver arranged to send radio packets to and receive radio packets from a server, and means for determining if the terminal and server are able to communicate. The terminal further comprises an outbox buffer, and a browser application for displaying content stored in the server. The browser application is arranged to initiate a first application by accessing a first item associated with the first application from the server using a first content identifier. The application being provided by the combination of the first item and further items each of which is accessible using an individual content identifier, and each of which comprises content, or means for linking to content. The browser further comprising means for creating content in association with an item and means for transferring messages comprising the created content to the server.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a radio terminal for browsing theInternet. It particularly relates to increasing the functionality ofsuch a terminal.

2. Description of the Prior Art

Mobile phones are becoming widely used as they provide security,mobility and flexibility. Recently the popularity of the Internet hasincreased among the general population. The Internet can be browsedusing a so-called browser application, which provides an easily usablevisual interface. It would be particularly desirable to combine the handheld nature of a mobile phone and its associated portability with theability to browse the Internet. The wireless application protocol (WAP)has been developed with this purpose in mind. It allows a radio handsetto communicate with a transceiver at an Internet gateway and accessesthe Internet through a radio link. A Wireless Application Environmentwhich forms a upper layer of the WAP stack includes a microbrowser. Thebrowser uses wireless mark-up language (WML) and a lightweight mark-uplanguage, WMLScript a lightweight scripting language. WML implements acard and deck metaphor. The interaction of the browser and user isdescribed in a set of cards which are grouped together into a documentcommonly referred to as a deck. The user navigates to a card in a deck,reviews its content and then navigates to another card in the same deckor in a different deck. Decks of cards are transferred from originservers as needed.

A desktop computer or the like, has until now been the standard devicefor accessing the World Wide Web. The computer generally has a display,a cursor control and selecting device such as a mouse and a keyboard.When using a device to browse the World Wide Web, the device generallyexchanges information with the Internet gateway over a fixed highband-width link. The device acts as a client and the Internet as aserver. The browser can access an ‘item’ of content using a URL. Thisitem allows access to further items of content each of which comprisescontent or means for linking to content. Typically content is downloadedfrom the Internet to the device to allow a browser application in thedevice to display one page having a number of icons which are ‘active’.Choosing and selecting an icon using the cursor control and selectiondevice activates a ‘link’ to another defined page. The browserapplication requests this page from the Internet gateway acting asserver. Content downloaded from the Internet to the device allows thebrowser application to display the page, which has been linked to. Thispage may in turn display ‘active’ icons for uses selection. The browserapplication mediates between the user and the Internet. It sendsrequests to the Internet and receives content therefrom.

The content received from the Internet may be instructions allowing thebrowser application to recreate a page with the correct links. It may,however, be content which cannot be processed by the browser applicationbut which requires a separate different application such as an emailapplication, a news reading application, etc. Portable terminals andhand held devices in particular have limited processing and memoryresources. It is desirable to maximize their resources by integratingthese applications with the browser without significantly increasing thecomplexity of the browser application itself. Such integration mayrequire modification of the Wireless Application Protocol and inparticular modification of WML and/or WMLScript.

SUMMARY OF THE INVENTION

It would be desirable to use a browser to provide the functionality ofother applications in a portable terminal which communicates over aradio link with a server while maintaining the simple functionality ofthe browser. It would be desirable if the applications did not require apermanent high bandwidth link between the terminal and server.

According to one aspect of the present invention there is provided aterminal for providing an application using a browser, comprising:

a transceiver arranged to send radio packets to and receive radiopackets from a server;

means for determining if the terminal and server are able tocommunicate; an outbox buffer; and

a browser application for displaying content stored in the server,arranged to initiate a first application by accessing a first itemassociated with the first application from the server using a firstcontent identifier, the application being provided by the combination ofthe first item and further items each of which is accessible using anindividual content identifier, and each of which comprises content, ormeans for linking to content, the browser further comprising means forcreating content in association with an item and means for transferringmessages comprising the created content to the server, wherein if theterminal and server are able to communicate, the browser sends themessages to the server and if the terminal and server are unable tocommunicate, the browser temporarily stores the messages in the outboxuntil the terminal and server are able to communicate when the storedmessages are automatically sent to the server.

According to another aspect of the present invention there is provided asystem comprising a server and a terminal for providing an applicationusing a browser, the terminal comprising:

a transceiver arranged to send radio packets to and receive radiopackets from the server;

means for determining if the terminal and server are able tocommunicate; an outbox buffer; and

a browser application for displaying content stored in the server,arranged to initiate a first application by accessing a first itemassociated with the first application from the server using a firstcontent identifier, the application being provided by the combination ofthe first item and further items each of which is accessible using anindividual content identifier, and each of which comprises content, ormeans for linking to content, the browser further comprising means forcreating content in association with an item and means for transferringmessages comprising the created content to the server,wherein if the terminal and server are able to communicate the browsersends the messages to the server and if the terminal and server areunable to communicate, the browser temporarily stores the messages inthe outbox until the terminal and server are able to communicate whenthe stored messages are automatically sent to the server.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention and to understandhow the same may be brought into effect reference will now be made byway of example only to the accompanying drawings in which:

FIGS. 1 and 2 schematically illustrate a radio handset;

FIG. 3 illustrates a network for accessing the Internet;

FIG. 4 is a schematic representation of the operation of a browserapplication in a terminal according to a first embodiment; and

FIGS. 5 a and 5 b illustrate the hierarchy of items used to provide anemail application and a news reading application respectively;

FIG. 6 illustrates the items in a hierarchy in more detail;

FIG. 7 is a schematic representation of a terminal according to a secondembodiment.

FIG. 8 represents an alternative hierarchy of decks suitable for use inthe browser of FIG. 7.

BEST MODE FOR CARRYING OUT THE INVENTION

FIGS. 1 and 2 illustrate a hand-portable radio communications device,henceforth referred to as a terminal or radio handset 2. The terminal 2is small enough to be carried by hand and is preferably sized to fitinto a pocket of a jacket. The terminal communicates with otherterminals or devices using radio waves.

The terminal 2 has a user interface comprising, for input, a keypad 24having keys 24 a and a microphone 20 and, for output, a speaker 18 and adisplay 14. The size of keypad 24 and display 14 are necessarily limitedby the size of the terminal 2. The terminal 2 is controlled bycontroller 4 and is powered by battery 26. The controller 4 receivessignals from the microphone 20 and the keypad 24 and provides signals tothe display 14 and the speaker 18. The terminal 2 has a transceiver 3,which is used to communicate outside the terminal 2. The transceiver 3is a radio frequency transceiver connected to an antenna 28 andcontroller 4. It is arranged to communicate via a radio frequencyinterface 30. The transceiver 3 includes a modulator 8 for modulatingsignals received from the controller 4 and a transmitter 6, whichpresents the modulated signals to the antenna 28. The transceiver 3 alsoincludes a receiver 12 which processes signals received at the antenna28 and provides them to a demodulator 10 which provides demodulatedsignals to the controller 4. The terminal 2 has a memory 16 which isconnected to the controller 4 via a bus. The terminal also has a SIMmemory 22 connected to the controller 4 which provides informationallowing the terminal 2 to function as a mobile phone. When functioningas a mobile phone, the terminal 2 transmits and receives radio frequencysignals via the antenna 28. The fundamental functions of the terminal 2are provided by the combination of the controller 4 and the memory 16.

The terminal 2 has a number of fundamental capabilities including systemcapabilities relating to radio communication. The terminal whenfunctioning as a phone will use standard communication protocols such asGSM, AMPS etc. and when functioning as an Internet terminal will use theWireless Application Protocol (WAP) The WAP protocol provides for a webbrowser.

FIG. 3 illustrates an Internet network 50 and a wireless network 60. TheInternet network comprises a web server 52 and a plurality of internetstations 54, which are clients to the web server 52. The Internetnetwork uses World Wide Web (WWW) protocols. The wireless network 60includes a plurality of wireless terminals 64, each of which can accessthe web server 52 via a protocol gateway 62. These terminals arepreferably hand-portable radio handsets. Communication between awireless terminal 64 and the protocol gateway 62 is according to theWireless Application Protocol (WAP). WAP specifies an applicationframework and network protocols for wireless terminals such as mobiletelephones, pagers and personal digital assistants. WAP brings Internetcontent and advanced data services to wireless terminals. WAP can workacross differing wireless network technologies and bearer types (GSM,CDMA, SMS). Communication between the web server 52 and protocol gateway62 is according to WWW protocols.

The wireless terminal differs from the Internet station in thatgenerally it has a less powerful CPU, less memory, restricted powerconsumption, smaller displays and more limited input devices. Thewireless network differs from the Internet network in that generally ithas less bandwidth, more latency, less connection stability and lesspredictable availability. The WAP architecture is optimized for narrowbandwidth bearers with potentially high latency and is optimized forefficient use of device resources.

Each device in a network is capable of sending and receiving packets ofinformation. A device may according to context be a server or a client,and a server may service a number of clients while being a client toanother server. Devices include the web server 52, the Internet stations54, the wireless terminals 64 and the protocol gateway 62. A wirelessterminal 64 acts as client and initiates a request for a connection withan origin server, the web server 52, to access a resource. The resource,identified by a URL (Uniform Resource Locator), is data (content) storedor generated at an origin server 52. The content is typically displayedor interpreted by the client. The protocol gateway translates requestsfrom the WAP protocol stack used by the wireless terminal 64 to the WWW(World Wide Web) protocol stack used by the web server. The web servereither returns WAP content such as WML (Wireless Markup Language) or WWWcontent such as HTML (HyperText Markup Language). In the later case afilter is used to translate the WWW content to WAP content e.g. HTML toWML. The protocol gateway also encodes content sent over the wirelessnetwork to the wireless terminal and decodes data sent to it by thewireless terminal.

WAP defines a set of standard protocols that enable communicationbetween mobile terminals and network servers. WAP uses a standard namingmodel according to which standard Internet URLs are used to identifycontent on origin servers. It also uses content typing. All WAP contentis given a specific type consistent with WWW typing which allows awireless terminal to correctly process the content based on type. WAPalso uses standard content formats and standard communication protocols.

A Wireless Application Environment which forms a upper layer of the WAPstack includes a microbrowser. The browser uses wireless markup language(WML) and a lightweight markup language, WMLScript a lightweightscripting language. Embodiments of the present invention provide thefunctionality of additional applications, for example email applicationsor news reader applications by creating extensions to WML and WMLScript.This allows the processing power of the terminal to be restricted,allows a standard WAP browser to be used and provides flexibility fornew features.

FIG. 4 is a schematic illustration of the operation of a browserapplication 100 in a terminal 2. The browser application provides thenormal browsing functions provided by WAP up until this time but inaddition provides other additional functions through the browserapplication such as email applications and news reading applications.The additional applications are provided by transferring content to theterminal. The content provides a hierarchy of decks which is used by thebrowser to emulate an additional application. The “master copy” of thecontent for emulating the additional application in the browser isstored and retained in the server. Any update or change to the contentin the browser occurring during the use of the additional applicationmust be communicated to the server so that the “master copy” of thecontent can be updated.

The figure includes the antenna 28 which communicates over the interface30, the transceiver 3, the browser application 100, a cache memory 110which may be part of the controller 4 or memory 16 in FIG. 1, anarbitrator 120, an outbox 130, an outbox controller 140 and the input24.

The transceiver 3 receives messages from the arbitrator 120 fortransmission over the interface 30 and supplies messages 121 receivedover the interface 30 to the arbitrator 120. The arbitrator 120determines whether a received message is in response to a request fromthe browser (synchronous) or is not in response to a request from thebrowser but pushed from the server over interface 30 (asynchronous). Anidentifier in the messages transmitted over the interface 30 identifieswhether the received messages are synchronous or asynchronous. Thearbitrator 120 determines from the identifier whether a received messageis synchronous or asynchronous and directs the received asynchronousmessages 122 to the cache memory 110 and directs the receivedsynchronous messages 124 to the browser 100. The browser 100 onreceiving a message 124 accesses and responds to its content, it thensends the content 102 to the cache memory 110 where it is stored suchthat it can be accessed using the content's URL. The content in thereceived asynchronous message is stored in the cache memory 110 suchthat it can be accessed using the content's URL. The cache is unitaryand is not partitioned. The content stored in the cache is not stored indifferent segments depending on the application it relates to. Thecontent for all applications is stored in the undivided cache. This maybe on a first in first out basis or alternatively the content could havedifferent priorities with the order of deletion of the content from thememory being dependent upon the priorities.

In the browser application URLs are used to access content. First thebrowser attempts to access the content in the cache 110 using thecorrect URL. If the content is stored in the cache it is read 104 fromthe cache into the browser. If the content is not in the cache, the readis unsuccessful and the browser synchronously requests the content fromthe server over the interface 30. The browser creates a message 108containing the required content's URL and sends the message to theserver over the interface 30. The browser then waits for a synchronousreply message 124 containing the required content to be returned by theserver over the interface 30 and directed by the arbitrator 120 to thebrowser 110. The browser then responds to the received content.

The server can provide push content to the terminal asynchronouslywithout the content being requested. The arbitrator 120 directs thisreceived content to the cache 110 where it can be accessed by thebrowser at a later time.

The browser 100 when emulating an application, can modify the “mastercopy” of the content stored in the server. This “master copy” istransferred in whole or in part to the terminal to emulate theapplication. The modification is effected by sending asynchronousmessages 106 from the browser to the server. The messages are sent fromthe browser 100 to the outbox 130. The outbox 130 under the control ofthe enable/disable signal 142 provided by the outbox controller 140 cansend the messages to the server via the interface 30. When the outboxcontroller 140 disables the outbox 130, the outbox buffers the messages106. When the outbox controller 140 enables the outbox 140 the outbox130 empties automatically and continues to empty automatically untildisabled. When the outbox empties the messages stored there aretransferred to the transceiver for transmission. The outbox controller140 receives a input control signal 144 from the transceiver 3. Thissignal controls whether the controller 140 enables or disables theoutbox 130. When the transceiver is able to communicate with the serverover the interface 30 the input control signal 144 enables the outbox130. When the transceiver is unable to communicate with the server overthe interface 30 for example because the transceiver is disabled, theterminal is out of radio coverage of the server or the radio interfacebetween the server and terminal is degraded, then the input controlsignal 144 disables the outbox 130 and the asynchronous messages 106 arebuffered. The outbox can be controlled by adding new library calls toexisting WMLScript functionality.

The input 24 when activated provides a signal which disable thetransceiver 3. Disablement of the transceiver prevents communicationover the interface 30 but does not otherwise affect the terminal. Thusthe browser application may be used in situations where radiotransmission is undesirable for example on an airplane. In particular itmay be used to access the additional functions provided by the browser,for example, off-line email reading and composing, re-plying topreviously received emails and off-line news reading. The actionsundertaken while off-line which affect the “master copy” of the contentused for emulating the active application(s) in the browser are storedas messages 106 in the outbox 130 and sent when the terminal comeson-line again.

FIG. 5 a illustrates a hierarchy of inter-linked items each of whichcontains content. The combination of items is used to emulate anapplication in a browser of a terminal. The items are stored in theserver as a “master copy” and are transferable to a terminal to emulatean application. The items are maintained in the server and transferredto the terminal over the interface as and when necessary. Although theitems may be modified by using the browser, the items maintained in theserver must be brought into conformity with any such modifications.

In the example shown, the items in combination provide the functionalityof an email application. A first item 160 provides user selectable links161, 163, 165 to respective further items 162, 164 and 166. The item 160and each of the further items 162 are each created from a deck. In thisexample the first item provides on the terminal display a list 170 ofuser selectable links 161, 163–165 each of which represents an email.Selection of a link accesses the appropriate further item and displaysthe text of an email on the display. Each of the links has two portions.A first text portion 172 gives a description of the link, in this casethe date and author of each email, and a second text portion 174 gives avisual indication of a parameter associated with that link. In this casethe parameter indicates whether a link has previously been activated (R)to read the email or not activated (U). It is apparent therefore thatoperation of the application may change the content received at thebrowser for example changing the parameter from indicating U to R. Thebrowser will update the items in the server to reflect the modificationsusing the asynchronous messages 106.

Typically the email application would be accessed through a bookmarklist in the browser which lists a number of favorite internet pages andthe email application. Each of the entries has an associated URL andselecting an entry in a bookmark list causes the browser to access thecontent associated with the URL. The cache 110 will be accessed firstand if the content is not present, a request will be made over theinterface 30 to the server. The email application entry in the bookmarklist is associated with the URL of the first item (the deck) 160.Accessing the first item 160 automatically provides the means foraccessing the remaining further items which provide the emailapplication. The further items are accessed by reading them from thecache and if this is unsuccessful by transferring them over theinterface 30.

FIG. 5 b is similar to FIG. 5 a and illustrates a hierarchy of itemscontaining content. The items in combination provide the functionalityof a news reader application. As previously a first Item 160 providesuser selectable links 161, 163, 165 to respective further items 162, 164and 166. The item 160 and each of the further items 162 are each createdfrom a so-called deck In WAP. In this example the first item provides onthe terminal display a list 170 of user selectable links 161, 163, 165each of which represents a news piece. Selection of a link accesses theappropriate further item and displays the text of the news piece on thedisplay. Each of the links has two portions. A first text portion 172gives a description of the link, in this case the date and news headlineof each news piece, and a second text portion 174 gives a visualindication of a parameter associated with that link. In this case theparameter indicates whether a link has previously been activated (R) toread the news piece or not activated (U).

FIG. 6 illustrates the hierarchy of content items which co-operate toprovide the functionality of an additional application to the browser.The “master copy” of this content is stored on the server. Each of thecontent items has an individual URL and can be accessed by the browserusing the URL. Access in this context means that if the item is storedin the cache it will be read from the cache using its URL and processedin the browser, and if the item is not stored in the cache, the browserwill request the item using its URL from the server over the interface30. The first item 160 is a deck called the Main deck and it identifiesthe other items and their URLs to the browser. The Main Deck 160 isaccessed by first getting the Main Deck's URL. If the Main Deck isstored in the cache, the URL will be used to load the Main Deck from thecache otherwise the browser requests the deck from the server over theinterface 30 using the URL. The Main Deck's URL may be obtained byselecting a bookmark in the browser application which is associated withthe URL of the Main Deck or by reading the URL from a SIM on which theMain Deck's URL is stored. Thus operators could pre-program SIM cardsbefore release with the URL's for the additional applications theysupport.

The Main Deck 160 comprises three cards: the Start Card 200, the OptionCard 210 and the Exit Card 220. Each of the cards has an individual URL.When the Main deck is loaded into the browser, the Start Card isautomatically activated. The start card has a first portion 202 whichdefines a number of parameters (SCR1, SCR2, SCR3) each of which isassigned a value reflecting the value of the parameter in the “mastercopy” of the content stored in the server. The second portion 204 of theStart Card 200 updates the parameter values to reflect the value of theparameters stored locally in the terminal. As will become clear in thefollowing, the second portion 204 sequentially effects access to theitems (Link Decks) 230, 240 and 250 which form the next level in thehierarchy, each of which respectively effects access to the items(Storage Decks) 260, 262 and 264. Thus portion 204 ensures that the LinkDecks and Storage Decks are loaded into the cache from the server if notalready there.

The Option card 210 is entered on reaching the end of the Start Card200. The option card has a number of portions 212, each of which isassociated with a defined one of the Link Decks 230, 240, 250 in thesecond layer of hierarchy. On entering the Option Card the portions areautomatically activated sequentially creating user selectable links 161,163 etc. on the display of the terminal. On activation of each portion212, a first function call 214 automatically provides the text indiciaon the display indicating the presence of the user selectable link 161and a second function call 216 automatically creates a user actuatedlink 161 to a defined content item in one of the Link Decks 230 in thesecond layer of the hierarchy. The first function call 214 provides thefirst text portion 172 and the second text potion or indicia 174 on thescreen. The text portion or indicia 174 is dependent upon the localvalue of a parameter assigned in the second portion 204 of the StartCard 200. The links created by the second functions 216 are activated bythe user selecting the link 161 displayed. Activation by the user causesthe browser to access the defined content item in the second layer ofhierarchy. The browser first tries to load the content item from thecache and if unsuccessful requests its transfer from the server.

The Exit Card is accessed when the application entered through the MainDeck 160 and represented by the hierarchy of content items in FIG. 6 isexited. The exit card controls the creation of the asynchronous messages106 which are sent to the outbox, and ensures that the “master copy” ofthe content items stored in the server representing the application areupdated to reflect any modifications effected by the browser.

The Link Deck 230 comprises a first card 232 and a second card 234. Thedeck is called a link deck as each provides for access from the MainDeck 160 to a pair of further items in the third level of hierarchy,namely a WML Deck which is a deck comprising content such as an email ornews piece, and a Storage Deck which is a deck storing parametersassociated with the WML Deck in the pair such as where the email or newspiece has been read. The Link Deck 230 provides for access from the MainDeck 160 to the WML Deck 162 and the Storage Deck 260. The Link deck 240provides for access from the Main Deck 160 to the WML Deck 164 and theStorage Deck 262. The link deck 250 provides for access from the MainDeck 160 to the WML Deck 166 and the Storage Deck 264

In the link deck 230, the first card 232 is accessed when the functionCall Init_SCR1 in the second portion 204 of the Start Card 200 isactivated. The browser attempts to access the card 232 using its URLfrom the cache, if it is unsuccessful, the browser requests the transferof the deck 230 comprising card 232 from the server. Once the card 232has been accessed, Init_SCR1 in card 232 is activated which accesses thestorage deck 260 using its URL and returns the parameter value(s) storedtherein as SCR1. The storage deck is accessed by first reading the cacheusing its URL and then if necessary requesting the transfer of thestorage deck 260 from the server using its URL. Thus the function CallInit_SCR1 ensures the link deck 230 and storage deck 260 are storedlocally in the cache and accesses the parameter value(s) stored in theStorage Deck.

In the link deck 230, the second card 234 is accessed when the secondfunction call 216 of a portion 212 of the Option Card 210 is activatedby selection of a link 161 by a user. The browser accesses the secondcard 234 by attempting to read the second card 234 from the cache 110using its individual URL and if it is unsuccessful by requestingtransfer of the deck 230 from the server. When the second card 234 isaccessed, two functions are carried out. First, the browser accesses thestorage deck 260 and updates the stored parameters there to indicatethat the link provided by the link deck 230 has been activated. This inthe examples given previously will adapt the content in the storage deck260 so that the value SCR1 will create a symbol R as opposed to U on thescreen when the first function call 214 of portion 212 in the OptionCard creates the text/indicia 174 on the display. Second, the browser100 accesses the deck 162 and processes the content therein. This accessin the previous examples displays the text of an email or a news piece.As previously when the browser accesses an item, it uses the item's URLto attempt to read the item from the cache and if this is unsuccessfulrequests the transfer of the item from the server.

It should be appreciated that loading the Main Deck into the browserautomatically provides means for creating the hierarchy of items withinthe terminal. The first portion 202 of the Start Card 200 brings theparameter values into line with the “master values” in the server. Thesecond portion 204 of the Start Card 200 brings the parameter valuesinto line with those stored locally in Storage Decks within the cacheand transfers any Storage Decks or Link Decks from the server to theterminal which are not in the terminal's cache. Each portion 212 of theOption Card 210 creates a user selectable link and indicates the link onthe display. The indication identifies whether the link has previouslybeen activated which fact is derived from one of the parameter values.

The deck 162 when loaded in the browser creates a text message and anumber of links which the user can use to return to the first level ofhierarchy of the application or to leave the application altogether. Aback option provides a link to the Main Deck using its URL. Userselection of the link makes the browser access the Main Deck 160. Themain Deck 160 is then loaded into the browser from the cache using itsURL or, if necessary, from the server using its URL. An exit optionprovides for an exit from the application and entry of the main menu anda bookmark option allows the user to exit the application by selecting abookmark which may represent another application or a link to othercontent not related to an application. User selection of the exit optionor a bookmark is detected as an event in the browser and an eventhandler is arranged to control the subsequent action. When the exitoption is selected, the Exit Card is accessed using its URL before themain menu is entered. When the bookmark is selected, the Exit Card isaccessed using its URL before the content identified by the bookmark isaccessed. When accessing the Exit Card 220, the browser first attemptsto read the Exit Card from the cache 110 using its URL and ifunsuccessful requests transfer of the Main Deck from the server and thenreads the Exit Card 220.

The exit card 220 is used to keep the “master records” stored in theserver in line with the records stored and updated in the browser. Thestorage decks 260 each store parameters which may vary during anapplication session. For example the parameter indicating whether a mailor news piece has been read will change if the deck containing the emailor news is accessed also a parameter may indicate that the user haschosen to delete a news piece or email. The exit card creates a message106 which identifies the new values of the changed parameters and sendsit asynchronously to the outbox 130. The message is formed by accessingthe storage decks 260, 262. This involves accessing the first card 232,242, 252 of the link decks 230, 240, 250 respectively to obtain the newparameter values SCR1, SCR2, SCR3. The storage decks are stored in thecache which is of a size such that storage decks of an activeapplication will not be deleted in the cache before the exit card sendsa message 106 to update the server. According to an alternativeembodiment the storage decks are prevented from being deleted from thecache until the server has been updated.

When a user of the terminal creates new content, for example, byauthoring an email, this content is sent to the server using a message106.

When the server receives a message 106 from the terminal, it updates the“master copy” of the content in the first example given above, itupdates the values of the parameters SCR1, SCR2, SCR3 etc. which havebeen varied by the browser and communicated to the server. The serverafter updating the “master copy” pushes the Main Deck 200 from the“master copy” to the terminal. The Main Deck is sent in a message withan asynchronous identifier. The terminal receives the pushed Deck anddirects it for storage in the cache,

The server can update the application by transferring items to theterminal after they have been requested, that is synchronously, orwithout them having been requested by the browser, that isasynchronously. The messages containing, the items which are sentasynchronously are directed to the cache. Thus the server can update theapplication when appropriate, for example when it receives a new emailor a new news piece.

If the terminal has a large enough cache, it would be possible to storeall the items of the hierarchy needed to perform the application in thecache. The browser would not then need to request items from the server.If the browser in such a terminal was not configured to amend thecontent received from the server, then it is not necessary for theterminal to be able to transmit to the server. The transceiver 3 couldin this case therefore be replaced by a receiver.

When the server receives a new item for the application, such as a newemail, it:-updates the Start Card 200 of Main Deck 160 by introducing anew entry to each of first and second portions 202 and 204; updates theOption Card 210 of the Main Deck 160 by introducing a new portion 212having first and second function calls 214 and 216; creates a new linkdeck having an individual URL and a first card accessible by the newentry in the second portion 204 of the Start Card 200 and a second cardaccessible on activating the link provided by the new portion 212 in theOption Card 210; creates new WML deck having an individual URLaccessible via the second card of the link deck which stores the text ofthe new email; and creates a new Storage Deck having an individual URLaccessible for reading from via the first card of the link deck andaccessible for writing to via the second card of the link deck whichstores a parameter indicating that the email is unread. The servercreates a message containing the updated Main Deck and pushes itasynchronously to the terminal. As an alternative, the server may createa message for each of the new decks in the hierarchy formed andconcatenate these messages and send the concatenated messageasynchronously to the terminal.

The link decks de-couple the Main Deck from the WML Decks and StorageDecks. The WML Decks may be replaced without adapting the Main Deck byadapting the relevant link decks. The link decks provide a standardinterface to the Main Deck while allowing the structure of the secondand third levels of the hierarchy to be varied without replacing theMain Deck.

FIG. 7 shows an alternative embodiment of the terminal previouslydescribed with relation to FIG. 4 and FIG. 8 shows an alternativehierarchy of decks suitable for use in the browser 100 of FIG. 7. Thedifference between the terminal 2 illustrated in FIG. 7 and thatillustrated in FIG. 4, is that the terminal illustrated in FIG. 7 doesnot have a cache 110. A consequence of not having a cache is that allaccesses made to items, whether decks or cards, using their URLs occursby sending a request to the server for the relevant deck to betransferred to the terminal. Another consequence is that the applicationemulated by the hierarchy of decks does not have local storage as thereis nowhere for the Storage Decks to be kept, thus Storage Decks areabsent from FIG. 8. The terminal informs the server when an actionoccurs which changes a parameter. Consequently, the second cards 234′,244′, 254′ of the link decks have a different first function call 236′,etc. to that described with relation to FIG. 6. The first function call236′ of the second cards 234′, 244′, 254′ creates an asynchronousmessage 106 which is placed in the outbox. This message informs theserver that the relevant WML Deck has been accessed and the serverresponds by adapting the relevant parameter and pushing a new Main Deck.The Main Deck 160 in FIG. 8 does not require an Exit Card 220′ as thereis no local storage.

Any annex attached to this application forms part of the presentdescription.

Although the invention has been described with respect to a particularlypreferred embodiment, it should be appreciated that the invention asdefined by the claims extends beyond the particular features of theembodiment described to encompass modifications and variations to theembodiment not necessarily described.

1. A terminal for providing an application using a browser, comprising:a transceiver arranged to send radio packets to and receive radiopackets from a server; means for determining if the terminal and serverare able to communicate; an outbox buffer; and a browser application fordisplaying content stored in the server, arranged to initiate a firstapplication by accessing a first item associated with the firstapplication from the server using a first content identifier, theapplication being provided by the combination of the first item andfurther items each of which is accessible using an individual contentidentifier, and each of which comprises content, or means for linking tocontent, the browser further comprising means for creating content inassociation with an item and means for transferring messages comprisingthe created content to the server, wherein if the terminal and serverare able to communicate the browser sends the messages to the server andif the terminal and server are unable to communicate the browsertemporarily stores the messages in the outbox until the terminal andserver are able to communicate when the stored messages areautomatically sent to the server.
 2. A terminal as claimed in claim 1,wherein the means for transferring messages updates the items stored inthe server for transfer to the terminal.
 3. A terminal as claimed inclaim 1, wherein the means for creating content creates a new furtheritem which is then transferred by the means for transferring content. 4.A terminal as claimed in claim 1, wherein the means for creating contentadapts the content of an existing item which is then transferred by themeans for transferring content.
 5. A terminal as claimed in claim 1,wherein the means for creating content creates content in dependence onthe accessing of items by the browser.
 6. A terminal as claimed in claim5, wherein the means for creating content identifies that an item hasbeen accessed.
 7. A terminal as claimed in claim 1, wherein pairs of thefurther items are associated, the first further item of the pair holdingcontent for access by the browser and viewing by the user and the secondfurther item of the pair storing content identifying a parameterassociated with first item.
 8. A terminal as claimed in claim 2, whereinthe parameter identifies whether the first further item has beenaccessed by the browser and viewed by the user.
 9. A terminal as claimedin claim 8, wherein the means for creating content adapts the parameterof the second further item of a pair of further items when the firstfurther item of the pair is accessed by the browser.
 10. A terminal asclaimed in claim 1, wherein the second further item of the pair is usedto provide a visual indication on the display.
 11. A terminal as claimedin claim 1, wherein the means for transferring the created contentcomposes a message comprising the created content for transfer to theserver.
 12. A terminal as claimed in claim 11, wherein the message issent asynchronously to the server by the means for transferring content.13. A terminal as claimed in claim 10, wherein the message is stored inan output box buffer in the terminal until there is radio communicationbetween the server and the terminal and is then emptied automatically.14. A terminal as claimed in claim 10, wherein the means fortransferring the content is activated on exiting an application.
 15. Aterminal as claimed in claim 1, wherein the first item is a deck and themeans for transferring content is a card in the first item.
 16. Aterminal as claimed in claim 1, wherein each further item has means forexiting the further item when accessed by the browser, whereinactivation of the exiting means updates the server and then the servertransfers the updated item or items to the terminal.
 17. A terminal asclaimed in claim 1, wherein a further item when accessed by the browserhas exit means for exciting the further item and simultaneously exitingthe application.
 18. A terminal as claimed in claim 17, wherein the exitmeans is an event handler activated by the creation of an event onexiting an item accessed by the browser.
 19. A system comprising aserver and a terminal for providing an application using a browser, theterminal comprising: a transceiver arranged to send radio packets to andreceive radio packets from the server; means for determining if theterminal and server are able to communicate; an outbox buffer; and abrowser application for displaying content stored in the server,arranged to initiate a first application by accessing a first itemassociated with the first application from the server using a firstcontent identifier, the application being provided by the combination ofthe first item and further items each of which is accessible using anindividual content identifier, and each of which comprises content, ormeans for linking to content, the browser further comprising means forcreating content in association with an item and means for transferringmessages comprising the created content to the server, wherein if theterminal and server are able to communicate the browser sends themessages to the server and if the terminal and server are unable tocommunicate the browser temporarily stores the messages in the outboxuntil the terminal and server are able to communicate when the storedmessages are automatically sent to the server.